Application programs come in many varieties, from the simple to the complex. For example, some application programs are standalone and are configured to run as a single discrete executable entity. Often, these standalone application programs are locally installed and executed on independent computing systems operated by or otherwise under the control of a single user, or perhaps by multiple users of the same household.
For example, desktop computing systems based financial management programs exist as application programs that execute on a standalone computing system such as a desktop computing system, interacting directly with the user, typically accessing a network for a very narrow range of reasons, such as to receive updates to the application program.
Other application programs are configured as network accessible application programs which have remote users logging in from other computing systems, and also which may use network-accessible services provided by other computing systems, such as databases and other services known to those of ordinary skill.
In each of the situations above, the standalone computing system environment and the network accessible computing system environment, the application program and any data the application program requires in order to properly perform one or more application program functions are both tightly coupled. Thus, when a designer of a given implementation of an application program becomes aware that a change needs to be made, for example, to the data that an application program uses, such as when a portion of the application program should consider additional details relating to its consumer users in order to provide an optimized user interface to the consumer user, it is often necessary to make significant changes to related application program functionality, in order to accommodate the different data needs.
In one example, financial management and other application programs occasionally make divisions based on consumer user input received through application program provided user interfaces. However, due to the application program having the decision-making functionality built into one or more application program modules, making change to the considered data is quite burdensome and typically requires that changes only be make when the application program is expected to undergo a new release from a first older version to a second newer version.
When the application program id large-scale and serves thousands of users at any given moment, replacing a first version of an application program with a later second version may affect hundreds or thousands of parties who are using the application program.
Further, software companies face decisions every day regarding appropriately coupling/decoupling the myriad systems upon which the business relies. As a business and its customers evolve, organizations often restructure themselves into groups of people with specializations in very particular areas of a problem space. Company organizations often have teams of people specializing in marketing, analytics, experience design, tax law, and other specializations.
In addition to being appropriately versed in their problem space, a successful team needs to be empowered to implement a potential solution quickly, receive feedback on that solution and immediately turn around another improved solution. Such teams are often burdened by waiting for major release dates, for example, because waiting for a given release date to occur and new data resulting from the given release to be collected and new models developed take a ling time, largely due to the tightly coupled nature of application program development and release cycles.
In terms of a decision modeling team, whose responsibility is to ensure that accurate decision models are enabled in a given application program so that when a decision is needed which will result in a change to application program functionality, the correct data is considered to arrive at a correct result.
However, a critical component that is missing, due to the tightly coupled nature of the application program to the decision functionality, is the ability for the decision model team to quickly publish their solution and take measurements on the results.
Because the data science teams work with the same application program that manages and controls all aspects of functionality, they must pursue application program development that tightly couples the solution to the body of the application program. Even in the best cases, the teams operate with significantly reduced agility due to needing to share a single deployment cycle. In the worst cases, this kind of integration is not even possible because the solution is particularly greedy in space (memory) and/or time (processing resources), that the consuming application's hardware is not able to accommodate it without a significant retooling of the deployment architecture.